1. User Interfaces
User interfaces for computer systems are well known in the art. In general, such user interfaces serve as the means through which users interact with the computer systems.
More particularly, in the usual case, the user interface comprises a screen display through which the computer system presents the user with computer output. Such output may serve to present the user with the opportunity to enter commands, to prompt the user to input data, to display data to the user, etc. The user interacts with the computer system by entering commands and/or data through the user interface, using various input devices such as a keyboard, mouse, etc. The specific manner in which the user interface functions generally defines the way in which the user can interact with the computer system.
In single user computer systems, the user interface is generally identical for all users once the system has been initially configured. However, in multi-user computer systems, it is common for the user interface to be specially configured for each different class or category of computer user. Such an arrangement is generally quite useful for two different reasons. First, by presenting each different class or category of user with thier own unique user interface, the computer system's utility can be enhanced for each different type of user. Second, by specially configuring the user interface for each different class of user, access to the system can be controlled according to user type. Generally, the highest class of user (typically referred to as the system "administrator") is given unlimited access to the system, while the other classes or categories of users are given more restricted levels of access to the system.
For example, in the case of a multi-user process control system, it would be common for the system administrator to have full access to the computer system. Therefore, the user interface for the administrator would typically provide the administrator with access to all of the command choices and all of the system data for the process control system. The user interface for the administrator might also provide the administrator with access to some or all of the computer system's underlying program code as well. However, in such a process control system, a lower level user (e.g. a maintenance engineer) might typically have access to only some of the features of the system. For example, the maintenance engineer might be able to view selected information on the status of a system component (e.g. the state of a valve), but might not be able to issue a command to change the state of that component (e.g. to open or close the valve). Therefore, the user interface for the maintenance engineer would typically be customized so as to provide that user with only the desired level of access to the system.
In the vast majority of prior art multi-user computer systems, the user interface must generally be custom built for each different type of user having access to the system. More particularly, in most prior art multi-user systems, each different application program must generally include a special block of code to create the unique user interface for each different type of user. These blocks of interface code form an integral part of each application program and provide the means by which the different users can interact with the system. Thus, the special blocks of interface code can to some extent be considered "enabling", in the sense that they must be specially created for each different type of user in order to permit that user to interact with the computer system.
See, for example, FIG. 1, which shows a typical prior art multi-user computer system comprising an operating environment, an application program, and a plurality of "enabling" user interfaces. It will be appreciated that with such a multi-user computer system, where the user interface is based on an "additive" approach, the special block of code provided to handle the user interface for the lowest level user will generally be the least complex, while the special block of code provided to handle the user interface for the highest level user (i.e., the administrator) will generally be the most complex.
Unfortunately, while the foregoing architecture does permit the user interface to be customized for each different type of user, it also requires a very substantial amount of time and effort to build the unique user interface needed for each different type of user.
A radically different approach is used in G2 .RTM. Ver. 2.11B, a prior art multi-user real-time expert system created by Gensym Corporation of Cambridge, Mass. More particularly, in G2 Ver. 2.11B, the operating environment and the application program are arranged so that the user interface for each different user type is initially fully enabled for that user type. G2 Ver. 2.11B provides means, in the form of an access restriction system, to disable selected interface features for each different type of user. By selectively disabling interface features on a "personalized" basis, the desired unique user interface can be provided for each different type of user. Thus, the G2 Ver. 2.11B access restriction system can to some extent be considered "disabling", in the sense that access restrictions are used to selectively withdraw user access according to user type.
See, for example, FIG. 2, which shows a typical G2 Ver. 2.11B computer system comprising an operating environment, an application program, and a plurality of "disabling" access restriction interfaces. It will be appreciated that with such a computer system, where the user interface is based on a "subtractive" approach, the access restriction system for the highest level user (i.e., the administrator) will generally be the least complex, while the access restriction system for the lowest level user will generally be the most complex.
More complete details on the G2 Ver 2.11B access restriction system will now be provided.
2. Introduction to the G2 Ver. 2.11B Access Restriction System
The G2 Ver. 2.11B access restriction system has two basic purposes: first, to configure the behavior of the user interface; and second, to control the ability of different users (having differing access privileges) to view and modify information, initiate activities, and modify the behavior of a G2 Ver. 2.11B application.
Some specific examples of this might be as follows:
causing a button when pushed to execute a specific activity which could be either internal to G2 Ver. 2.11B (e.g. causing a display to appear) or external to G2 Ver. 2.11B (e.g. causing a valve to open); PA1 making this button inoperative when pushed by some users; PA1 allowing some users to see certain displays of information on workspaces, and keeping them off-limits for other users; PA1 allowing some users to view certain attributes of an object as shown in a table, and preventing other users from viewing the same attributes; PA1 allowing some users to view and modify certain attributes of an object as shown in a table, and other users to view but not to modify them; PA1 allowing some users to modify a schematic presented on a workspace, and other users only to view the schematic, where the modifications may include adding new icons, deleting existing icons, moving the icons around on the schematic, making or breaking connections between icons, changing the orientation of icons, and changing the colors of icons and connections; PA1 allowing some users to create, modify and delete programmatic and behavioral aspects of a G2 Ver. 2.11B application (such as rules, formulas, procedures, and class definitions) while preventing other users from doing any of these things. PA1 change-size PA1 clone PA1 color PA1 create-subworkspace PA1 delete PA1 edit PA1 move PA1 name PA1 rotate-reflect PA1 table PA1 transfer PA1 new-object PA1 new-rule PA1 new-display PA1 new-free-text PA1 new-button PA1 hide-workspace PA1 delete-workspace PA1 move the item if it has an icon or text region by dragging it with the mouse; PA1 move a workspace by dragging it with the mouse; PA1 extend connections, make corners in them, and connect them to other icons; PA1 open a text region for editing or typing (this is how a user types into a field in a dialog). PA1 (a) Removing Menu Choices PA1 menu choices for workspace exclude: new-object PA1 (b) Removing Non-Menu Choices PA1 non-menu choices for furnace exclude: move-object PA1 (c) Selecting For Action PA1 selecting any subworkspace-button implies go-to-subworkspace PA1 (d) Removing Attributes from an Attribute Table PA1 attributes visible for procedure exclude: text PA1 or PA1 attributes visible for plant exclude: profit-margin PA1 (e) Modifying the Behavior of an Attribute Table PA1 table menu choices for control-panel exclude: edit PA1 or PA1 table menu choices for the price or discount of any merchandise exclude: edit PA1 the user restrictions for the item that the gesture applies to are read, each clause being read from bottom to top, which is the reverse of the order in which they are displayed in a table; PA1 continuing to traverse up the workspace hierarchy, that is, from workspace to the item that it is a subworkspace of, or from an item upon a workspace to the workspace, or from an attribute of an item to the item that it is an attribute of, until one arrives at a top-level workspace; PA1 then reading the restrictions in the kb-restrictions system table from bottom to top. PA1 when in &lt;mode or modes&gt;: . . . PA1 unless in &lt;mode or modes&gt;: . . . PA1 includes PA1 includes additionally PA1 excludes PA1 excludes additionally PA1 implies PA1 the user mode of the user's window; PA1 the item; PA1 the set of menu choices applicable to the item in the absence of any user restrictions; PA1 the path up the workspace hierarchy starting with the item and ending with a top level workspace, and the user restrictions, if any, in each of these items; PA1 the user restrictions in kb-restrictions. PA1 the user restrictions are read in the bottom up order previously described--each group of user restrictions has a mode filter, and the group is ignored unless the mode filter indicates that the group applies based upon the user mode; PA1 only clauses that begin with menu choices for or selecting any . . . implies are applicable in this context (other clauses apply to non-selecting gestures, and to table display and interaction)--the rest are ignored; PA1 only user restriction clauses that apply to a class that the item is a member of are applicable, the rest are ignored (i.e., the class or classes listed near the beginning of the user restriction clause must contain at least one class in the class inheritance path of the item); PA1 the search must end either with a subset of the original menu choices with which to build the menu, or with the decision to execute one of them without displaying a menu, or with no action; PA1 a menu choice will be executed rather than a menu being displayed if a user restriction clause containing selecting any . . . implies is read on the search before a clause containing exclude or include (but without additionally) is encountered; PA1 if there is no such selecting any clause, then the menu choices must be filtered--the following describes the filter as applying to a single choice from among the set of menu choices that would have appeared absent any user restrictions, however, the actual search is done for the entire group so as to be efficient:
The G2 Ver. 2.11B access restriction system can be used to achieve any of the foregoing in a uniform way over a large application. At the same time, however, the G2 Ver. 2.11B access restriction system can also be applied in great detail to small portions of an application. Thus, it is capable of making local exceptions to global access restrictions.
A complete understanding of the G2 Ver. 2.11B access restriction system requires a broader understanding of the organization, components and basic interactions of G2 Ver. 2.11B. Accordingly, these will be reviewed next.
3. Important Concepts in G2 Ver. 2.11B
3.1 The Workspace Hierarchy.
The workspace hierarchy refers to the organizational layout or geography of a G2 Ver. 2.11B application. It can be viewed as a hypertext having the form of a forest, as will hereinafter be discussed in further detail.
In one form, a workspace is a rectangular bordered area upon which other items may be positioned. The items that appear on a workspace are visually of three types: icons, connections and messages. Icons are images having a fixed design. This design is governed by the class of the item that the icon represents. Connections are linear (stretchable) pathways extending between icons. They vary in thickness and in cross-sectional pattern. Messages are textual displays which are confined to a rectangular region.
See, for example, FIG. 3. FIG. 3 shows a G2 Ver. 2.11B screen display 5 which comprises a first workspace 10 and a second workspace 15. Various icons 20, connections 25 and messages 30 are shown on workspaces 10 and 15.
Some icons may have workspaces associated with them. This is called the subworkspace of the icon. This is a logical association, and should not be confused with the workspace that the icon appears on. For example, there may be a button on a workspace and when that button is pushed, it may cause another workspace which is the subworkspace of the button to be displayed.
See, for example, FIG. 4. FIG. 4 shows a G2 Ver. 2.11B screen display 40 which comprises workspaces 45, 50, 55, 60 and 65, wherein workspace 50 has two icons 70 and 75 thereon, and workspaces 60 and 65 constitute the subworkspaces of icons 70 and 75, respectively. It should be noted that FIG. 4 is to some extent conceptual in nature, since in G2 Ver. 2.11B workspaces and the subworkspaces of icons placed on those workspaces are not normally simultaneously displayed on the same screen.
A workspace that is not a subworkspace of any icon is called a top-level workspace. A top-level workspace may have icons on it which have subworkspaces associated with them. These subworkspaces may in turn may have other icons upon them which have further subworkspaces associated with these other icons. In this way workspaces may be seen to branch out from one another. A branching structure of this type having a single root is generally called a tree. The root of the tree is the top-level workspace that is the starting point to reach everything below it.
See, for example, FIG. 5, which shows a simple tree structure for a G2 Ver. 2.11B application. More particularly, FIG. 5 shows a G2 Ver. 2.11B screen display 80 which comprises three top-level workspaces 85, 90 and 95. Top-level workspace 85 has no icons placed thereon. Top-level workspace 90 has an icon 100 placed thereon, and a workspace 105 is the subworkspace of this icon 100. Workspace 105 in turn has three icons 110, 115 and 120 placed thereon, and workspaces 125, 130 and 135 are the subworkspaces of these three icons, respectively, Top-level workspace 95 has two icons 140 and 145 placed thereon, and workspaces 150 and 155 are the subworkspaces of these two icons, respectively. Again, it should be noted that FIG. 5 is to some extent conceptual in nature, since in G2 Ver. 2.11B workspaces and the subworkspaces of icons placed on those workspaces are not normally simultaneously displayed on the same screen.
In G2 Ver. 2.11B, an item may be an attribute of another item. The item which is an attribute of another item also belongs on this tree, just below the item that it is an attribute of. A G2 Ver. 2.11B application may have more than one top-level workspace, which is why it is sometimes convenient to consider workspaces in the context of a forest. In G2 Ver. 2.11B, the structure of the forest is called the workspace hierarchy. It is important to understand that the relationship among the different workspaces is a logical one, and that most of this structure is not visually apparent to the user at any given time. An application may have many workspaces, and only a small number of these can typically be shown at the same time in a G2 Ver. 2.11B window on the screen of a monitor.
The importance of the workspace hierarchy is that it provides an orderly and logical way to organize all the different parts of a G2 Ver. 2.11B application. The workspace hierarchy can be built with as much depth as is needed to serve its many purposes. For example, one part of the workspace hierarchy may contain programmatic material that most end users never see. This may be organized into several subsections for the different functional parts of the application. Each of these might be further subdivided so that there are places for class definitions, for rules, for procedures, etc. Another part of the workspace hierarchy might contain schematics for the end user. For example, there might be a single processing plant schematic, with detailed schematics of parts of the plant positioned on subworkspaces of the top level schematic. This might extend downward for several levels. Other workspaces might be used for displays, graphs, dialogs, etc.
This concept of workspace hierarchy is essential to the G2 Ver. 2.11B access restriction system. In particular, and as described in detail below, access restrictions (known as user restrictions) are implemented in G2 Ver. 2.11B by means of the workspace hierarchy. These user restrictions are essentially rules written according to a predetermined convention which govern the various characteristics of the user interface. A given user restriction applies to the specific workspace in which it is placed, and to all of the workspaces located below that workspace. Thus, the effect of a user restriction depends upon precisely where it is placed in the workspace hierarchy. If it is placed on a top-level workspace, it will apply to everything in the entire tree below that workspace. If it is placed further down the workspace hierarchy, it applies to a smaller region geographically. Since some user restrictions can be used to make exceptions to other user restrictions, it becomes easy to assert some behavior globally, and to retract it for one specific portion of the application.
3.2 The Class Hierarchy
G2 Ver. 2.11B can be used to implement applications that use the object oriented design paradigm. One of the important principles of such object oriented design is that of inheritance of important properties by means of a class hierarchy.
In G2 Ver. 2.11B, all items belong to classes. Some classes are built into G2 Ver. 2.11B as predefined classes, and some classes are user defined. Whenever a class is defined, it must be given a superior class, unless it is the basic class item. As a consequence, all classes form a tree which is called the class hierarchy. See, for example, FIG. 6, which shows a simple, illustrative class hierarchy relating to valves.
When a person refers to the class of an item, they generally mean the most specific class that the item is a member of. But an item is also a member of all of its superior classes. Thus, for example, if a G2 Ver. 2.11B item is a two-door-coupe, it may also be a passenger-car, a motor-vehicle, a manufactured-product, an object and an item. It simultaneously belongs to all of these classes by way of inheritance.
In G2 Ver. 2.11B, as in other object oriented definitional systems, attributes of objects are inherited by subclasses. For example, if horsepower is an attribute of the "higher" class motor-vehicle, then it will also be an attribute of the "lower" class two-door-coupe. In G2 Ver. 2.11B, the specification that motor-vehicle has an attribute called horsepower is placed in an item called the object-definition for the class motor-vehicle. Inheritance into subclasses is automatic in G2 Ver. 2.11B.
It should be appreciated that the class hierarchy is a very different type of hierarchy from the workspace hierarchy. Both types of hierarchy are present in G2 Ver. 2.11B, but each one relates to something quite different.
More particularly, the class hierarchy is a classification system, as is the hierarchy called taxonomy in natural science. (Chimpanzee is a subclass of primate. Primate is a subclass of mammal, etc.) A subclass is always a more restrictive and specific class of its superior class. Items belong to thier immediate class and to all superior classes.
The workspace hierarchy, on the other hand, has nothing to do with classification. It is an organizational system for subdividing a whole into parts and subparts. It is geographic in nature. It is like saying that Nebraska is part of the United States, and Lincoln is part of Nebraska. Or again, it is like saying that a house has rooms, and rooms have windows and doors. In G2 Ver. 2.11B, one could have a schematic for the house on a workspace, and show a more detailed schematic for each room on a subworkspace. A room is part of a house. It is not a particular kind of a house.
In G2 Ver. 2.11B, user restrictions can be placed on workspaces and flow through the workspace hierarchy. User restrictions can also be placed on class definitions which are located within a given workspace. However, in G2 Ver. 2.11B, user restrictions which are placed on class definitions which are located within a given workspace do not flow outside that workspace through the class hierarchy; they can only flow outside that workspace, to the subworkspace (if any) of that class definition, through the workspace hierarchy.
3.3 Basics of the G2 Ver. 2.11B User Interface
In G2 Ver. 2.11B, access restrictions work by removing or modifying some of the interactive user interface behavior of the system. Thus it will be seen that, in order to properly understand the G2 Ver. 2.11B access restriction system, one must first understand how the basic G2 Ver. 2.11B user interface works. To that end, there now follows a simple description of the G2 Ver. 2.11B user interface, in the absence of any access restrictions.
In G2 Ver. 2.11B, the user interface is based largely upon menus. There is no menu bar in G2 Ver. 2.11B; instead, menus are created on the fly whenever there is a mouse click on the G2 Ver. 2.11B window.
For example, if the mouse is clicked on the G2 Ver. 2.11B window background or border where there is no workspace, then the Main Menu for G2 Ver. 2.11B is displayed. The Main Menu offers certain global choices such as Start. It also has several sub-menus which can logically be considered as part of the Main Menu. See, for example, FIG. 7, which shows a G2 Ver. 2.11B screen display 160 which comprises three workspaces 165, 170 and 175, a mouse pointer 180 which is located on the G2 Ver. 2.11B window background, and a Main Menu 185 which has been generated by clicking the mouse while mouse pointer 180 is located on the G2 Ver. 2.11B window background or border where there is no workspace.
If, on the other hand, the click is on a workspace but not on any item upon that workspace, then the workspace menu for that workspace is displayed. See, for example, FIG. 8, which shows a G2 Ver. 2.11B screen display 190 which comprises two workspaces 195 and 200 having icons 205, 210 and 215 thereon, as shown, a mouse pointer 220 which is located on workspace 195, and a workspace menu 225 which has been generated by clicking the mouse while mouse pointer 220 is located on workspace 195 but not on either of the items 205, 210.
If the click is on any item upon a workspace, then the menu for that item is displayed. This applies to icons, connections, and messages. See, for example, FIG. 9, which shows a G2 Ver. 2.11B screen display 230 which comprises two workspaces 235 and 240 having icons 245, 250 and 255 thereon, as shown, a mouse pointer 260 which is located on icon 250, and an item menu 265 for item 250 which has been generated by clicking the mouse while mouse pointer 260 is located on icon 250.
With the exception of the Main Menu and its sub-menus, every menu belongs to some item.
The menu for an item is the gateway to most ways of interacting with that item. Every item has built-in menu choices, as well as user defined ones. Some of the important item menu choices are:
Some other menu choices that appear only in workspace menus are:
Some menu choices lead to further menu choices. For example, selecting new-object leads to a further choice.
The things that one can do to an item other than to get its menu are called non-menu choices. The most important of these non-menu choices are:
Denying the user access to either menu choices or non-menu choices will prevent most forms of interaction, including, for example, the creation and deletion of items. This concept of denying the user access to either menu choices or non-menu choices is the essence behind the G2 Ver. 2.11B access restriction system, as will be discussed in further detail below.
It is important to appreciate that every item in G2 Ver. 2.11B has an attribute table. This table has rows, one for each attribute, and two columns, the cells of the left column for the name of the attribute and those of the right column for the value of the attribute. See, for example, FIG. 10, which shows a G2 Ver. 2.11B screen display 270 which comprises two workspaces 275 and 280. Workspace 275 has an item 285 thereon. Also shown is a workspace 290 which is a subworkspace of item 285, and an attribute table 295 which lists the various attributes of item 285. FIG. 10 also shows an attribute table 310 which lists the various attributes of the object which is the value of the cell 315 shown in attribute table 295. Again, it should be noted that FIG. 10 is to some extent conceptual in nature, since in G2 Ver. 2.11B at least some of the items shown would not normally be simultaneously displayed on the same screen.
Except for some attributes which are read only, the user can normally modify the value of an attribute by opening up the value cell of the table for editing. This can be done either by clicking on the text already in the cell, or by getting the menu for the cell and selecting edit.
Much of the important information in G2 Ver. 2.11B resides in the attributes of various items. For example, the text attribute of rules, formulas, procedures and functions contains the actual code of the item. Most information about the class hierarchy is contained in various attributes of class definitions. Thus, the ability to view and edit the attributes of items is quite important in G2 Ver. 2.11B. Correspondingly, the use of access restrictions to constrain the user's ability to view and edit the attributes of items is also very important in G2 Ver. 2.11B.
More particularly, through the use of appropriate access restrictions, a user can be prevented from viewing the attribute table for an item if clicking on the item does not display a menu, or if the menu does not offer the menu choice table. But access restrictions offer a further level of control than that. Even if the user is allowed to view the table, the rows representing some attributes may be omitted from the table, or the rows representing some attributes may be present in the table but the user's ability to edit or otherwise modify them has been removed, thereby making them read only.
3.4 Telewindows, User Modes, and Workspaces
As noted above, G2 Ver. 2.11B is a multi-user product. In addition to the many different types of networking that G2 Ver. 2.11B is capable of, a single G2 Ver. 2.11B application can be accessed by multiple users at the same time by means of an interface to G2 Ver. 2.11B called Telewindows.RTM.. This Telewindows interface simultaneously allows each user to have a different view of the same G2 Ver. 2.11B application, but with each user having different user privileges.
Under the Telewindows interface, each user may be in a different location on a computer network running a Telewindows interface program as a client, with the single G2 Ver. 2.11B program as the server. See, for example, FIG. 11, which shows such an arrangement. When the client Telewindow node connects to the server G2 Ver. 2.11B application, there is a log-in dialogue. As part of this log-in dialogue, the user must provide his or her name, password, and user mode. If G2 Ver. 2.11B has been installed as a secure system, it will use the password to verify the user, and only permit user modes that have been authorized for that user by the system administrator. It is important to recognize that each window connected to a G2 Ver. 2.11B application, regardless of whether it is a local window or a Telewindow node window, has a user mode associated with it.
The concept of user mode is central to the G2 Ver. 2.11B access restriction system. More particularly, the G2 Ver. 2.11B access restriction system uses constructs called user restrictions to configure the user interface differently for each different type of user. These user restrictions are filtered (or activated) according to user mode. Thus, it is the use of these user restrictions, in combination with the user mode feature, which gives G2 Ver. 2.11B the ability to have a user interface that responds in different ways for different users.
The set of possible user modes is open ended. Only one user mode is pre-defined in G2 Ver. 2.11B, i.e., the administrator mode. Whenever a user interacts with G2 Ver. 2.11B from a window, the user mode of the window is an important determinant of how the interaction proceeds.
The presentation of workspaces in a window is specific to that window and is independent of whether and how the workspace is presented in any other window. A G2 Ver. 2.11B application which is serving multiple windows must track, independently for each window, which workspaces are exposed in the window, the scale and position of each exposed workspace, and the front-to-back ordering of the exposed workspaces. In all other respects, the appearance of a workspace is the same in all windows in which it appears. This includes what items are placed on the workspace and where they are placed, as well as thier orientation and colors. For example, if an icon on a workspace is moving, it will appear to be moving in any window in which the workspace (and the particular region of the workspace in which the motion occurs) is visible.
As will be discussed in further detail below, the user mode of a window has a strong influence on what the user sees and what happens when the user attempts to interact with what he or she sees.
4. The G2 Ver. 2.11B Access Restriction System
In G2 Ver. 2.11B, the access restriction system is implemented through constructs called user restrictions. In order to properly understand the use of user restrictions in G2 Ver. 2.11B, one must first understand what user restrictions do, where they are placed in G2 Ver. 2.11B, the order in which they are read, how they are filtered according to user mode, and how they combine with one another.
4.1 What User Restrictions Do
User restrictions work by modifying or eliminating portions of the user interface. These are as follows:
Any choice offered on the Main Menu and its sub-menus, or on the menu for any item, may be removed. If all choices have been removed from a menu, the menu does not appear at all. Obviously, understanding the full power and use of this feature depends upon a strong familiarity with all the menu choices available on the various classes of items in G2 Ver. 2.11B.
An example of a user restriction clause removing a menu choice might be as follows:
User restrictions cannot make a menu choice appear on a menu that would not be there in the absence of restrictions. There is another feature of G2 Ver. 2.11B, the user-menu-choice item, which causes new menu choices to be added to menus, and specifies an action to be taken when that menu choice is selected by the user. User restrictions may remove these user-defined menu choices, as well as those that are built into G2 Ver. 2.11B.
If all menu choices have been removed, no menu appears upon clicking.
Any activity that can be performed on an item by means of the mouse or keyboard other than clicking to get its menu is called a non-menu choice. These non-menu choices include moving a workspace, scaling a workspace, moving an item on a workspace, dragging connections, and opening text regions for editing.
An example of a user restriction clause removing a non-menu choice might be as follows:
Removing such an option causes G2 Ver. 2.11B to be unresponsive to the particular keyboard or mouse activity.
This user restriction feature changes what happens when the user clicks on an item. Instead of getting the menu for the item, the activity caused by making one particular choice from that menu is immediately invoked. The user restriction does not describe or specify an activity. It directs the user interface to proceed as if the menu had been displayed and the user had then selected a menu choice from the menu, but without actually displaying a menu or waiting for the user to make a choice.
An example of a user restriction clause selecting a menu choice for action might be as follows:
This feature allows the G2 Ver. 2.11B user interface builder to create various buttons that cause specific things to happen. The specific menu choice which is selected for action can be either a built-in menu choice or a user-defined menu choice.
This feature removes specified attributes from the attribute tables of specified classes.
Examples of user restriction clauses which remove attributes from an attribute table might be as follows:
The attribute being removed from an attribute table can be either built-in or user defined, as can be the class. This type of user restriction can be used to remove some types of user information from some users, but it can also be used to remove programmatic capability from some users, since important aspects of the G2 Ver. 2.11B programming language are found in built-in attributes of certain types of items.
Table menu choices offer a wide range of control over the behavior and interactions of tables. For example, one can control the editing of attribute values so as to make them read only. This can be done either for all the attributes of a table, or for just some particular attributes.
Examples of user restriction clauses which modify the behavior of an attribute table might be:
4.2 Where User Restrictions are Placed in G2 Ver. 2.11B
User restrictions are placed in two different locations within G2 Ver. 2.11B. Thier scope depends on where they are placed. The syntax of the user restrictions is tailored somewhat according to thier specific location, although they tend to be quite similar to each other.
User restrictions may be placed in the user-restrictions attribute of every item. The scope of user restrictions placed in the user-restrictions attribute of an item is that portion of the workspace hierarchy of which that item is the root, i.e, they govern that item, and they are inherited from items to thier subworkspaces, from items to thier attributes which are items, and from workspaces to the items upon the workspace.
User restrictions may also be placed in the user-restrictions attribute of the kb-restrictions system table. This is a single global location in G2 Ver. 2.11B. The scope of user restrictions placed in the user-restrictions attribute of the kb-restrictions system table is global. This is the only place in G2 Ver. 2.11B where it is possible to put menu restrictions on the Main Menu.
4.3 When and in What Order User Restrictions are Read
User restrictions become applicable when the user interacting with a window makes a gesture such that it is appropriate to display the Main Menu, display the menu of some item, otherwise manipulate some item, display a table, or interact with a table. In every case, there is a window from which the gesture is made, and in every case except for displaying the Main Menu, there is an item associated with the gesture.
Each location where user restrictions may be placed may contain a sequence of user restriction clauses. The order in which these user restriction clauses are read is very important. Some user restrictions may have a wide scope, and other user restrictions--which may or may not be intended as exceptions to the earlier ones--may have a much more local scope. For the purpose of reading and understanding user restrictions, it is sometimes useful to read them top down, because it is usually easier to understand a general rule and then deal with the exceptions later. But for the purpose of explaining exactly how user restrictions are implemented, it is better to read them bottom up, since this is how G2 Ver. 2.11B actually implements user restrictions. The reason for proceeding in this order is that once the exception is encountered, it is typically unnecessary to consult the general rule. Thus, in G2 Ver. 2.11B, the implementation of user restrictions causes them to be read from the bottom up.
The order in which user restrictions are read, using the bottom up convention, is as follows:
The one exception to this is the Main Menu, where there is no item. Main menu user restrictions are found in the main-menu-user-restrictions attribute of kb-restrictions.
See FIG. 11A, which illustrates the order in which user restrictions are read in G2 Ver. 2.11B.
By way of further example, FIG. 11B shows a G2 Ver. 2.11B screen display 1005 that comprises a top-level workspace 1010, an item 1015 placed upon top-level workspace 1010, a workspace 1020 which is a subworkspace of item 1015, and an object 1025 which is placed upon workspace 1020. In the example of FIG. 11B, the user restrictions would be read in the order shown by following the arrows 1026A, 1026B, 1026C and 1026D, i.e., first one would read the user restrictions in the table for object 1025, then one would read the user restrictions in the table for subworkspace 1020, next one would read the user restrictions in the table for item 1015, then one would read the user restrictions in the table for workspace 1010, and finally one would read the user restrictions in the kb-restrictions table.
See also FIG. 11C, which shows a schematic flow chart illustrating the order in which the user restrictions would be read for the example shown in FIG. 11B.
FIG. 11D shows a related screen display 1005A for the same example, where top-level workspace 1010, item 1015, workspace 1020 and object 1025 are shown, as well as the attribute table 1025T for the object 1025, the attribute table 1020T for the workspace 1020, the attribute table 1015T for the item 1015, the attribute table 1010T for the workspace 1010, and the kb-restrictions table 1005T for the application running on screen displays 1005 and 1005A.
4.4 How User Restrictions are Filtered by User Mode
In G2 Ver. 2.11B, user restrictions are specified according to the following convention:
______________________________________ {none .vertline. when in &lt;user mode or modes&gt; mode : &lt;restriction or restrictions&gt; .vertline. unless in &lt;user mode or modes&gt; mode : &lt;restriction or restrictions&gt;} ______________________________________
Thus it will be seen that when reading user restrictions, groups of user restriction clauses are preceded by mode filters which are in the following form:
These mode filters determine whether the restriction clauses following the mode filter are read or ignored. As the grammar suggests, if the clause begins with when, then the restriction clauses are read if the user mode of the window from which the gesture was made is one of the modes that follow. If the mode filter begins with unless, the restriction clauses are read if the user mode is not one of the modes that follow.
In G2 Ver. 2.11B, there is one built-in mode having special behavior. This is the administrator mode. User restrictions never apply in administrator mode, and one may not specify when in administrator mode . . . , although one may specify unless in administrator mode . . . The reason for this is that allowing the construct when in administrator mode . . . could permit the developer of an application to unintentionally lock himself or herself out of portions of the application program.
4.5 Combining Principles of User Restrictions
Recall that in G2 Ver. 2.11B, user restrictions are specified according to the following convention:
______________________________________ {none .vertline. when in &lt;user mode or modes&gt; mode : &lt;restriction or restrictions&gt; .vertline. unless in &lt;user mode or modes&gt; mode : &lt;restriction or restrictions&gt;} ______________________________________
In this convention, the specific user restriction clauses follow the mode filters discussed above.
G2 Ver. 2.11B provides five different kinds of user restriction clauses. They are specified according to the following conventions:
______________________________________ menu choices for &lt;class or classes&gt; {include [additionally] .vertline. exclude [additionally]}: &lt;menu choices&gt; non-menu choices for &lt;class or classes&gt; {include [additionally] .vertline. exclude [additionally]}: &lt;non-menu choices&gt; selecting any &lt;class or classes&gt; implies &lt;menu choice&gt; attributes visible for &lt;class or classes&gt; {include [additionally] .vertline. exclude [additionally]} : &lt;attribute names&gt; table menu choices for [the &lt;attribute names&gt; of] any &lt;class or classes&gt; {include [additionally] .vertline. exclude [additionally]} &lt;table menu choices&gt; ______________________________________
The user restriction clauses that follow the mode filters can both remove and add user interface capability in G2 Ver. 2.11B. In essence, anything that can be asserted on a higher level, either additive or subtractive, can be undone on a lower level in G2 Ver. 2.11B.
In G2 Ver. 2.11B, the user restriction clauses that follow the mode filters each have one of the following sets of words within the user restriction clause:
The user restriction clauses that involve menu choices and selection upon clicking will be explained in detail below. The behavior of the other user restriction clauses is similar in principle and follow from an understanding of the former.
The user restriction clauses that involve menu choices and selection upon clicking have the following general grammar:
______________________________________ menu choices for &lt;class or classes&gt; {include [additionally] .vertline. exclude [additionally]}: &lt;menu choices&gt; selecting any &lt;class or classes&gt; implies &lt;menu choice&gt; ______________________________________
User restriction clauses of this type are applicable when the user clicks on an item. In the absence of user restrictions, G2 Ver. 2.11B would display a menu for the item on the user's window. The user restrictions modify this so that either the menu appears but with some of its choices removed, or one of the choices is executed without displaying the menu.
The information available with which to conduct the user restriction search is the following:
The user restriction search proceeds in this manner:
include--if the choice is not listed, it is not included, and the search is over; if the choice is listed, it is included and the search is over; PA2 include additionally--if the choice is not listed, the search continues; if the choice is listed, it is included and the search is over; PA2 exclude--if the choice is listed, it is not included and the search is over; if the choice is not listed, it is included and the search is over; PA2 exclude additionally--if the choice is listed, it is not included and the search is over; if the choice is not listed, the search continues; PA2 if the search ends with no decision, the menu choice is included.
As noted previously, it is frequently easier to understand the logic of how user restrictions work if one considers how they read in English in top down order. To do this, read them starting with the kb-restrictions, and then read the user restrictions starting with those in the top level workspace and descending the workspace hierarchy, ending with the user restrictions in the item toward which the user's gesture is made.
Restrictions beginning with menu choices for . . . include: are intended to furnish a complete specification of included menu choices for the listed classes, with the presumption that all others are excluded. It is a general declaration, and overrules any statement made at a higher level. But it may have exceptions at a lower level.
User restrictions beginning with menu choices for . . . exclude: are similar in scope, but complementary in that they furnish a complete specification by listing all menu choices that are to be excluded, with the presumption that all others are included.
User restriction of the form menu choices for . . . include additionally and menu choices for . . . exclude additionally are intended to modify the specification inherited from a higher level by including or excluding some more menu choices respectively. These declarations make no assumption about menu choices they do not specifically mention.
User restrictions beginning with selecting any . . . implies are intended to override menu choices generally, and to replace them with the execution of a single action. A selecting any user restriction placed at a higher level can be overridden by one placed at a lower level.
5. Inadequacies of the G2 Ver. 2.11B Access Restriction System
The access restriction system of G2 Ver. 2.11B has proven to be an extremely convenient and versatile means for configuring a user interface. Unfortunately, however, it has also been found that the user restriction construct employed in the access restriction system of G2 Ver. 2.11B is not adequate for all purposes.
More particularly, as noted above, in G2 Ver 2.11B user restrictions cannot be applied against the system administrator. This is a deliberate design feature of G2 Ver. 2.11B, based on the premise that the system administrator should generally be able to view and modify all aspects of the application program. As a consequence of this design choice, however, it has also been discovered that vendors marketing customized G2 Ver. 2.11B applications to end users lack suitable means for preventing the end user's administrator from viewing and modifying various aspects of the vendor's application program, More particularly, in G2 Ver 2.11B the vendor is able set up user restrictions which restrict the access of all non-administrators from vendor-created workspaces, but the vendor is unable to set up any user restrictions which will prevent the end user's administrator from gaining access to all aspects of the application program, including vendor-created workspaces.
See, for example, FIG. 12, which shows a G2 Ver. 2.11B screen display 320. Display 320 comprises a vendor-created workspace 325 having a vendor-created class definition 330 thereon, and a user-created workspace 335 having an object 340 thereon, where object 340 is an instance of the class represented by class definition 330. In this situation, the end user's administrator could gain access not only to the user-created workspace 335, but also to the vendor-created workspace 325 and to the vendor-created class definition 330.
It has been recognized that such administrator access to vendor-created workspaces can present serious concerns for the vendor, for two different reasons. First, the vendor-created workspaces frequently contain valuable trade secrets and work product of the vendor which the vendor may wish to keep confidential. Obviously the contents of such vendor-created workspaces cannot remain confidential so long as the end user's administrator can obtain access to these workspaces. Seconds and perhaps more importantly, many G2 Ver. 2.11B applications are used to control critical manufacturing and/or service-related processes, where system failures could have serious safety and/or economic consequences. On account of this, the vendor frequently needs to ensure that certain critical, time-proven sections of the application program be effectively secured against any alteration by the end user, since such alteration could undermine the system's integrity and thereby render it unreliable.
On account of the foregoing, vendors of G2 Ver. 2.11B application programs have tried a variety of different techniques in an effort to prevent the end user's administrator from gaining access to vendor-created workspaces.
For example, some vendors have deleted source code remarks from, and altered meaningful object names in, the distributed application program in an effort to inhibit end user administrators from viewing and modifying the application program. While the use of such techniques can help conceal the vendor's trade secrets and work product to some extent, it is generally not completely successful in this respect. Furthermore, the use of such techniques is generally not preferred since it tends to complicate and undermine the vendor's own maintenance of the application program. In addition, the use of the foregoing techniques still does not prevent end user administrators from copying various vendor-created objects into user-created workspaces, nor does it prevent end user administrators from then using these objects in thier own user-created workspaces. It will be appreciated that such a practice can seriously undermine program integrity, particularly where helpful source code remarks have been deleted and meaningful object names altered.
In view of the foregoing, G2 Ver. 2.11B provides that certain workspaces may be declared to be proprietary. This is done by giving the workspace the appropriate attribute in its attribute table. By definition, once a workspace has been made proprietary, all users--including administrators--are barred from thereafter cloning or transferring any items on that proprietary workspace. Thus, vendors can to some extent restrict access to a vendor-created workspace by declaring that workspace to be proprietary before shipping the application program to the end user; thereafter no end user--including the administrator--will be able to clone or transfer any items on that proprietary workspace. Unfortunately, however, the proprietary declaration construct of G2 Ver. 2.11B is only able to provide the vendor with a rough tool for restricting end user access to a vendor-created workspace, since it is predefined in scope and principally prohibits the subsequent cloning and transferring of objects placed upon a proprietary workspace. Thus, for example, an end user administrator can still view, among other things, the attributes of any objects placed upon a vendor-created workspace which has been declared proprietary.
On account of the foregoing, it has been recognized that an improved access restriction system is needed in order to allow vendors to quickly, easily and effectively prevent end user administrators from gaining any access to vendor-created workspaces.